Method and system for user-designed application deployment

ABSTRACT

Embodiments of a method and system for utilizing user-designed applications are disclosed. A user-designed application that utilizes at least one high-level API available within a system may be received. The user-designed application may be deployed server-side within the system. A user request may be processed server-side for the user-designed application in the system.

PRIORITY CLAIM

This application is a continuation of U.S. patent application Ser. No.14/137,753, filed on Dec. 20, 2013, which is a continuation of U.S.patent application Ser. No. 11/740,689, filed on Apr. 26, 2007, whichclaims the priority benefit of U.S. Provisional Application No.60/745,989, filed Apr. 28, 2006, which are incorporated herein byreference in their entirety.

TECHNICAL FIELD

The present application relates generally to the field of dataprocessing and, in one specific example, to a method and system foruser-designed application deployment.

BACKGROUND

Applications created by external developers to work with a systemprovided by another tend to be operated external to the system. Theexternal developers incur the costs of running the created applicationincluding costs in trying to promote availability of the createdapplication. The external developers may receive compensation from anoperator of the system, from advertisers providing content to beavailable on the application, and the like. However, the compensationmay be insufficient to cover the expenses incurred or to justify thedevelopment of a new application.

The external developers are not alone in increased cost. A significantissue for an operator of the system is that the use of many low-levelapplication program interface (APIs) are needed by external developersto create an application with value. A developer may use a low-level APIfor each call to a server located in the system. For instance, a simpleapplication may require one call to get information about a set ofitems, then calls for data about each item, then more calls forinformation about the users that created those items. So a simple searchquery could easily become a series of hundreds of remote API calls. Ifthese calls had to be done sequentially, and each call tookapproximately 100 ms, such a page could take many minutes to create.

High-level API's, in contrast to the low-level API's, may handle thesimple interactions of many lower-level APIs in a controlled way tominimize the number of sequential calls. The high-level APIs may includethe many calls of the low-level APIs but may be optimized forperformance (e.g., some of the calls may be performed simultaneously).However, because high-level APIs are typically created to address theperformance issues of having a complex set of logic to render the finalresultant data set, these higher-level APIs are often representative ofvery specific use-cases and may be unrelated to an application createdan external developer. Because of this, an external developer may belimited to taking the data from an existing page and combining it withadditional data on the client's side.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments are illustrated by way of example and not limitation inthe figures of the accompanying drawings in which:

FIG. 1 is a block diagram of a system;

FIG. 2 is an example programmable application that may be deployedwithin the system of FIG. 1;

FIG. 3 is an example client that may be deployed within the system ofFIG. 1;

FIG. 4 is a flowchart illustrating a method for utilizing auser-designed application according to an example embodiment;

FIG. 5 is a flowchart illustrating a method for receiving auser-designed application according to an example embodiment;

FIG. 6 is a flowchart illustrating a method for utilizing auser-designed interface according to an example embodiment;

FIG. 7 is a flowchart illustrating a method for managing one or moreresources according to an example embodiment;

FIG. 8 is a flowchart illustrating a method for using a user-designedinterface according to an example embodiment;

FIG. 9 is a flowchart illustrating a method for using a client accordingto an example embodiment;

FIG. 10 is a network diagram depicting a network system, according toone embodiment, having a client server architecture configured forexchanging data over a network;

FIG. 11 is a block diagram illustrating an example embodiment ofmultiple network and marketplace applications, which are provided aspart of the network-based marketplace; and

FIG. 12 is a block diagram diagrammatic representation of machine in theexample form of a computer system within which a set of instructions,for causing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed.

DETAILED DESCRIPTION

Example methods and systems for user-designed application deployment aredescribed. In the following description, for purposes of explanation,numerous specific details are set forth in order to provide a thoroughunderstanding of example embodiments. It will be evident, however, toone skilled in the art that the present invention may be practicedwithout these specific detail

In an example embodiment, a user-designed interface that utilizes atleast one high-level application program interface (API) may bereceived. The user-designed interface may be deployed server-side withina system. A user request may be processed server-side through theuser-designed interface with a server in the system.

In an example embodiment, a user-designed application that utilizes atleast one high-level application program interface (API) availablewithin a system may be received. The user-designed application may bedeployed server-side within the system. A user request may be processedserver-side for the user-designed application in the system.

In an example embodiment, an access request may be received for asystem. A user-designed interface deployed server-side within the systemmay be selected. A user request may be processed server-side through theuser-designed interface with a server in the system.

In an example embodiment, a plurality of low-level application programinterfaces (APIs) that communicate with a server in a system may beselected. The plurality of low-level APIs to be embodied as at least onehigh-level API. A user-designed interface capable of utilizing the atleast one high-level API when deployed in the system may be created. Theselection of the plurality of low-level APIs and the user-designedinterface may be provided to an operator of the system.

FIG. 1 illustrates a system 100 in which a client machine 102 maycommunicate over a network 104 with a system server 106. The network 104may be a Global System for Mobile Communications (GSM) network, anInternet Protocol (IP) network, a Wireless Application Protocol (WAP)network, or a Wifi network, as well as various combinations thereof.Other conventional and/or later developed wired and wireless networksmay also be used.

The system server 106 may make a user-designed application 114 availablefor use by the client 110 using a plurality of low-level applicationprogram interfaces (APIs) deployed as at least one-high level API 118.The user-designed applications 114 may be an application developed byexternal developers (e.g., not employees) that may deployed and utilizedinside the system 100. The system server 106 may include a number ofother components not shown, and may optionally be capable ofload-balancing the programmable application 112 and/or the othercomponents. An example embodiment of the programmable application 112 isdescribed in greater detail below.

In an example embodiment, the user-designed applications 114 may bemanaged by the programmable application 112 to make optimized use of oneor more resources within the system 100 according to a grid managementframework. The grid management framework may be an enterprise gridalliance (EGA) framework that may be used to manage the user-designedapplications 114 within the system 100. However, other frameworks thatmanage the user-designed applications 114 and other resources of thesystem 100 may also be used. The framework may optionally provide anexecution space that may enforce the barriers and the privileges of thesystem 100 such as memory and CPU utilization restrictions, the abilityto create threads, or the ability to access external data sources, andthe like.

The user-designed application 114 may include a user-designed interface,an advertising application or other application that is availableinternally in the system server 106 to the client 110. The user-designedapplications 114 may be serviced internally or externally.

The user-designed interface may include, by way of example, a customizedinterface, direct access to select items and/or groupings of itemsavailable within the system 100 (e.g., as company data 120 in a database108) or another system, links to content available outside the system100, and the like. By way of an example, a medical-oriented userinterface may include links to medical items being sold at a variableprice and a fixed price within the system 100, stores available fromother users with the system 100 that are selling medial items, reviewsof the medical items, and other medical information. The user-designedapplication 114 may increase the likelihood that a transaction withinthe system 100 will be conducted by a user of the user-designedapplication 114.

The low-level APIs 116 may expose a single function or sets of functionsavailable within the system server 106. Examples of functionalityprovided by the low-level APIs 116 may include, by way of example,access to company data 120 (e.g., records) in the database 108 ortransformation of one format of data into another form. The low-levelAPIs 116 may be, in an example embodiment, a getItem or getUser APIcall. However, other types of functionality and other API calls may alsobe used. Available low-level APIs 116 in the system 100 may be madeavailable to a developer in the form a Software Development Kit (SDK)that the developer can develop against or otherwise.

The user-designed application 114 may avoid latency when utilizing atleast one high-level API 118 as opposed to the plurality of low-levelAPIs 116. A high-level API 118 may, for example, may implement fiftycalls of a plurality of low-level APIs 116 to the system 100 in a singlecall. The high-level APIs 118 may handle simple interactions oflower-level data in a controlled way to minimize the number ofsequential calls.

The client machine 102 may present the received content on a userinterface to a user (e.g., on a display) through a client 110. Thecontent may include, by way of example, items available for purchase ata fixed or variable fee, information regarding a number of items, linksto websites and other network resources, and the like. Examples of theclient machine 102 include a set-top box, a receiver card, a mobilephone, and a computing system; however other devices may also be used.

The database 108 may include company data 120 and/or user applicationdata 122. The user application data 122 may be code (e.g., source and/orobject code) that may be used to implement the functionality of theuser-designed applications 114, low-level APIs 116, and/or thehigh-level APIs 118. The company data 120 may be provided to the client110 for presentation to a user within the user-designed applications114. For clarity and conciseness one database 108 is illustrated.However, multiple databases 108 may be employed as may be desired.

FIG. 2 illustrates an example programmable application 112 (see FIG. 1)that may be deployed in the system 100 or in another system. Theprogrammable application 112 may include a receiver module 202, adeployment module 204, a selection module 206, a request processingmodule 208, a resource management module 210, and/or a content module212. However, other modules may also be used.

The receiver module 202 receives a user-designed application 114 thatutilizes at least one high-level API available within the system 100.The deployment module 204 deploys the user-designed application 114server-side within the system 100.

The selection module 206 selects a user-designed application deployedserver-side within the system 100. The request processing module 208processes a user request server-side for the user-designed application114 in the system 100.

The resource management module 210 manages one or more resourcesassociated with the user-designed application 114. The content module212 provides content through a user-designed application 114 (e.g., theuser-designed interface) in response to processing the user requestand/or denies access through the user-designed application 114 whenutilization of the one or more resources of the system 100 exceed asystem threshold.

FIG. 3 illustrates an example client 110 (see FIG. 1) that may bedeployed in the system 100 or in another system. The programmableapplication 112 may an API selection module 302, an interface creationmodule 304, a selection providing module 306, a reporting module 308,and/or a compensation module 310. However, other modules may also beused.

The API selection module 302 selects a plurality of low-level APIs thatcommunicate with the system server 106 in the system 100 to be embodiedas at least one high-level API 118. The interface creation module 304creates a user-designed interface capable of utilizing the at least onehigh-level API 118 when deployed in the system 100.

The selection providing module 306 provides the selection of theplurality of low-level APIs 116 and the user-designed interface to thesystem 100. The reporting module 308 receives a report of utilization ofresources of the system 100 by the user-designed interface. Thecompensation module 310 receives compensation from an operator of thesystem 100.

FIG. 4 illustrates a method 400 for utilizing a user-designedapplication 114 (see FIG. 1) according to an example embodiment. Theuser-designed application 114 may be utilized in the system 100 or inanother system.

A request for a feature that utilizes at least one high-level API 118available within the system 100 may optionally be posted at block 402.The posted request may include desired features and/or functionality(e.g., a specially designed user interface for medical equipment) to beprovided with the system 100 by an external developer.

In response to the post, a notification of intent to create auser-designed application 114 that implements the feature may bereceived at block 404. The notification may be provided by one or moreexternal developers.

At least one user-designed application 114 that utilizes at least onehigh-level API 118 available within the system 100 (e.g., in the systemserver 106) may be received from one or more external developers atblock 406. The user-designed application 114 may be received from theprovider of the notification and may implement the feature as posted(see block 402).

In an example embodiment, programmable code may be received for aservice from the external developer, the programmable code may becompiled, and a user-designed application 114 that utilizes the at leastone high-level API and the compiled code may be received. The originalsource and the compiled version of the code may optionally both bestored in the database 108 (e.g., as user application data 122) toenable load-balanced application handling by a distributed subsystem ofthe system 100.

A user-designed application 114 may be selected at block 408. Theselected user-designed application may satisfy an acceptance criterion,and may be selected from among a plurality of user-designed applications114 provided for possible deployment.

In an example embodiment, a plurality of designed applications may bereceived from a plurality of external developers that utilize at leastone high-level API 118 available within the system 100 and implement thefeature. A selection of a user-designed application 114 may be made fromthe received designed applications.

A developer of the user-designed application may optionally becompensated at block 410. For example, the developer may be compensatedwhen the user-designed application 114 satisfies an acceptance criterionset by an operator of the system 100.

The user-designed application 114 may be deployed server-side within thesystem 100 at block 412 to enable processing of a user requestserver-side at block 414.

A determination may be made at decision block 416 whether to providecontent in response to the user request. If a determination is made toprovide content, content may be provided from the user-designedapplication in response to processing the user request at block 418. Ifa determination is made at decision block 416 not to provide content,access to content from the user-designed application 114 may be denied.For example, access may be denied when the utilization of the resourcesof the system 100 exceed a system threshold. The resources may include,by way of example, a number of cycles of a central processing unit(CPU), a memory, and/or a number of system calls. Upon completion of theoperations at block 418 or block 420, the method 400 may proceed todecision block 416.

At decision block 422, a determination made may be made whether tomanage one or more resources of the system 100. If a determination ismade to manage the resources, one or more resources of the system 100may be managed at block 424. For example, the one or more resourcesassociated with the user-designed application may optionally be managedin the grid management framework of the system 100. If a determinationis made not to manage the resources at decision block 422 or uponcompletion of the operations at block 424, the method 600 may proceed todecision block 426.

A determination may be made at decision block 426 whether to performfurther processing. If a determination is made to perform furtherprocessing, the method 400 may return to block 414. If a determinationis made not to perform further processing at decision block 426, themethod 400 may terminate.

In an example embodiment, the method 400 may provide a developmentopportunity for community driven innovation. For example, an externaldeveloper may create an interesting application for listing, presentingand ordering for a computer. By enabling the external developer toupload code and to use a reference to that code from other parts of anexisting website infrastructure, it may be possible for an operator tofully integrate, serve and manage this functionality from within thesystem 100.

FIG. 5 illustrates a method 500 for receiving a user-designedapplication 114 (see FIG. 1) according to an example embodiment. In anexample embodiment, the method 500 may be performed at block 406 (seeFIG. 4).

A selection of a plurality of low-level APIs 116 that communicate withthe system server 106 in the system 100 may be received at block 502.The selection may optionally include an acceptable API specificationfrom the external developer.

The plurality of low-level APIs 116 may be deployed as at least onehigh-level API 118 in the system 100 at block 504. The plurality oflow-level APIs 116 may be packaged or otherwise associated together asthe at least one high-level API 118 for deployment. The deployment ofthe at least one high-level API 118 within the system 100 may enablemore efficient processing of requests in the system 100 as compared toprocessing requests with the plurality of low-level APIs 116. In anexample embodiment, the at least one high-level API 118 may be definedby the client 110 by running generated code within the programmableapplication 112 and using the business objects and methods of the system100.

In an example embodiment, by moving the logic of how to deal with theexternal data model from the client-side to the system-side of thesystem 100 and presenting only the data that is of interest to theclient 110, stabilization of the user-designed application 114 may beachieved, while also granting flexibility to the external developer.

In an example embodiment, the at least one high-level API 118 mayoptionally be granted authorization to interact with various objects andmethods and potentially designate different service levels to differentusers. These authorizations may be aggregated into certain pre-definedroles such as business partner or public.

A user-designed application 114 that utilizes the at least onehigh-level API 118 may be received at block 506. The at least onehigh-level API and the user-designed application 114 may optionally betested server-side in the system 100 at block 508. The testing mayinsure ensure compliance, reliability and/or performance with the system100.

FIG. 6 illustrates a method 600 for utilizing a user-designed interfaceaccording to an example embodiment. The user-designed interface may beutilized in the system 100 or in another system.

A user-designed interface that utilizes at least one high-level API maybe received at block 602. The user-designed interface may be deployedserver-side within the system 100 at block 604 and may optionallyinclude user-provided content. The user-designed interface may provide adifferent, compelling, and/or unique experience to a user relative to astandard interface available with the system 100.

A user request may be processed server-side through the user-designedinterface with the system server 106 in the system 100 at block 606. Theuser request may include, by way of an example, a selection of an itemfor purchase or a selection of an item for bid.

A determination may be made at decision block 608 whether to providecontent. If a determination is made to provide content, content may beprovided through the user-designed interface in response to processingthe user request at block 610. If a determination is made at decisionblock 608 not to provide content, access to content through theuser-designed interface may be denied. For example, access may be deniedwhen the utilization of the resources of the system 100 exceeds a systemthreshold. Upon completion of the operations at block 610 or block 612,the method 600 may proceed to decision block 614.

At decision block 614, a determination made may be made whether tomanage one or more resources of the system 100. If a determination ismade to manage the resources, one or more resources of the system 100may be managed at block 616. If a determination is made not to managethe resources at decision block 614 or upon completion of the operationsat block 616, the method 600 may proceed to decision block 618.

A determination may be made at decision block 618 whether to performfurther processing. If a determination is made to perform furtherprocessing, the method 600 may return to block 606. If a determinationis made not to perform further processing at decision block 618, themethod 600 may terminate.

FIG. 7 illustrates a method 700 for managing one or more resources inthe system 100. In an example embodiment, the method 700 may beperformed at block 424 and/or block 616 (see FIGS. 4 and 6).

Utilization of one or more resources of the system 100 used by theuser-designed interface may be tracked at block 702. The tracking may bein the form a utilization profile of the user-designed interface or maybe otherwise tracked.

A determination may be made at decision block 704 whether to providecompensation. If a determination is made to provide compensation, anexternal developer of the user-designed application 114 may optionallybe provided compensation (e.g., directly to the developer or a person ororganization designated by the developer) at block 706. The compensationmay be based on, by way of example, the utilization of the resources bythe user-designed application and/or a number of transactions using theuser-designed application. The compensation may be provided by anoperator (e.g., dynamically by a compensation application or manually bya user) of the system 100, a lister of an item available in the system100 through the user-designed application, and/or a purchaser of theitem through the user-designed application.

Providing compensation to the external developer of the user-designedapplication may encourage other developers to create user-designedapplications for deployment within the system 100, thereby increasingthe functionality of the system 100 and reducing the development cost ofadditional functionality of the system 100. The developer of theuser-designed application may not need to make an effort to market theuser-designed application 114 to receive compensation, as the system 100and/or users of the system 100 may promote the use of the user-designedapplication 114. The compensation may reflect a value that theuser-designed application 114 has contributed to the system 100.

Providing compensation to an organization with whom the user-designedapplication 114 is associated (e.g., as designated by the externaldeveloper and/or an operator of the system 100 may encourage users toutilize the user-designed application to generate revenue for theorganization.

The tracked utilization of resources consumed by the user-designedapplication 114 may optionally be used in determining compensation sothat the external developer is only compensated for additional valueadded as a result of the deployed user-designed application 114. In anexample embodiment, when compensation is provided based on resource useof the system 100 versus revenue received (e.g., purchases of items)through use of the user-designed application 114, the operator may onlycompensate external developers that have provided value to the system100. For example, the value may be an increased amount of transactiondollars relative to resource cost.

If a determination is made at decision block 704 not to providecompensation or upon completion of the operations at block 706, themethod 700 may proceed to decision block 708.

At decision block 708, a determination may be made as to whether areport may be provided. If a determination is made to provide a report,a report of the utilization of the resources may be provided at block710 to the external developer or another designated party. The reportmay, by way of an example, enable the external developer to determine ifthe user-designed application 114 should be modified to run using fewerresources so that additional compensation may be received. If atdecision block 708 a determination is made not to provide the report orupon completion of the operations at block 710, the method 700 mayproceed to decision block 712.

A determination may be made at decision block 712 whether to charge forutilization of the user-designed application 114. If a determination ismade to charge, a charge may be made for the utilization of theresources of the system 100 beyond a system threshold. If at decisionblock 712 a determination is made not to charge or upon completion ofthe operations at block 714, the method 700 may proceed to decisionblock 716.

At decision block 716, a determination may be made whether to performfurther tracking. If further tracking is to be performed, the method 700may return to block 702. If a determination is made at decision block716 that further tracking is not to be performed, the method 700 mayterminate.

The determinations made at decision blocks 704, 708, 712 may occur inany order including multiple decision blocks occurring in parallel.

FIG. 8 illustrates a method for using a user-designed interfaceaccording to an example embodiment. The user-designed interface may bedeployed in the system 100 (see FIG. 1) or in another system.

An access request may be received for the system 100 at block 802

A user-designed interface deployed server-side within the system 100 maybe selected at block 804. The selection may be a dynamic selectionusing, by way of an example, a genetic algorithm. The selection may alsobe made by the user, and recommendations may be provided to a user ofone or more user-designed interfaces that may be of interest to the userand available within the system 100.

In an example embodiment, a plurality of available user-designedinterfaces deployed server-side within the system 100 may be identifiedand a selection of a user-designed interface from the plurality ofavailable user-designed interface may be received.

A user request may be processed server-side through the user-designedinterface with the system server 106 in the system 100 at block 806.

A determination may be made at decision block 808 whether to providecontent. If a determination is made to provide content, content may beprovided through the user-designed interface in response to processingthe user request at block 810. If a determination is made at decisionblock 808 not to provide content, access to content through theuser-designed interface may be denied. For example, access may be deniedwhen the utilization of the resources of the system 100 exceeds a systemthreshold, when a charge for utilization has not been paid, and thelike. Upon completion of the operations at block 810 or block 812, themethod 800 may proceed to decision block 814.

At decision block 814, a determination made may be made whether tomanage one or more resources of the system 100. If a determination ismade to manage the resources, one or more resources of the system 100may be managed at block 816. If a determination is made not to managethe resources at decision block 814 or upon completion of the operationsat block 816, the method 800 may proceed to decision block 818.

A determination may be made at decision block 818 whether to performfurther processing. If a determination is made to perform furtherprocessing, the method 800 may return to block 806. If a determinationis made not to perform further processing at decision block 818, themethod 800 may terminate.

FIG. 9 illustrates a method for using the client 110 (see FIG. 1). Theclient 110 may be used in the system 100 or in another system.

A plurality of APIs 116 that communicate with the system server 106 inthe system 100 may be selected at block 902. For example, an externaldeveloper may cause the selection of the low-level APIs 116 so that theprogrammable application 112 may embody the plurality of low-level APIs116 as at least one high-level API 118.

A user-designed interface capable of utilizing the at least onehigh-level API 118 when deployed in the system 100 may be created atblock 904. For example, a same external developer or a differentexternal developer that caused the creation of the at least onehigh-level API 118 may cause the creation of the user-designedinterface.

The selection of the plurality of low-level APIs 116 and theuser-designed interface may be provided from the client 110 (see FIG. 1)to an operator (e.g., the programmable application 112 for dynamicdeployment or a person for manual deployment) of the system 100 at block906.

A report of utilization of one or more resources of the system 100 bythe user-designed interface may optionally be received at block 908

Compensation from the operator of the system 100 may optionally bereceived at block 910.

FIG. 10 is a network diagram depicting a client-server system 1000,within which one example embodiment may be deployed. For example, thesystem 1000 may be deployed with the client-server system 1000 oranother system.

A networked system 1002, in the example forms of a network-basedmarketplace or publication system, provides server-side functionality,via a network 1004 (e.g., the Internet or Wide Area Network (WAN)) toone or more clients. FIG. 10 illustrates, for example, a web client 1006(e.g., a browser, such as the Internet Explorer browser developed byMicrosoft Corporation of Redmond, Wash. State), and a programmaticclient 1008 executing on respective client machines 1010 and 1012.

An Application Program Interface (API) server 1014 and a web server 1016are coupled to, and provide programmatic and web interfaces respectivelyto, one or more application servers 1018. The application servers 1018host one or more marketplace applications 1020 and payment applications1022. The application servers 1018 are, in turn, shown to be coupled toone or more databases servers 1024 that facilitate access to one or moredatabases 1026.

The marketplace applications 1020 may provide a number of marketplacefunctions and services to users that access the networked system 1002.The payment applications 1022 may likewise provide a number of paymentservices and functions to users. The payment applications 1022 may allowusers to accumulate value (e.g., in a commercial currency, such as theU.S. dollar, or a proprietary currency, such as “points”) in accounts,and then later to redeem the accumulated value for products (e.g., goodsor services) that are made available via the marketplace applications1020. While the marketplace and payment applications 1020 and 1022 areshown in FIG. 10 to both form part of the networked system 1002, inalternative embodiments the payment applications 1022 may form part of apayment service that is separate and distinct from the networked system1002.

Further, while the system 1000 shown in FIG. 10 employs a client-serverarchitecture, the present invention is of course not limited to such anarchitecture, and could equally well find application in a distributed,or peer-to-peer, architecture system, for example. The variousmarketplace and payment applications 1020 and 1022 could also beimplemented as standalone software programs, which do not necessarilyhave networking capabilities.

The web client 1006 accesses the various marketplace and paymentapplications 1020 and 1022 via the web interface supported by the webserver 1016. Similarly, the programmatic client 1008 accesses thevarious services and functions provided by the marketplace and paymentapplications 1020 and 1022 via the programmatic interface provided bythe API server 1014. The programmatic client 1008 may, for example, be aseller application (e.g., the TurboLister application developed by eBayInc., of San Jose, Calif.) to enable sellers to author and managelistings on the networked system 1002 in an off-line manner, and toperform batch-mode communications between the programmatic client 1008and the networked system 1002.

FIG. 10 also illustrates a third party application 1028, executing on athird party server machine 1030, as having programmatic access to thenetworked system 1002 via the programmatic interface provided by the APIserver 1014. For example, the third party application 1028 may,utilizing information retrieved from the networked system 1002, supportone or more features or functions on a website hosted by the thirdparty. The third party may, for example, provide one or morepromotional, marketplace or payment functions that are supported by therelevant applications of the networked system 1002.

FIG. 11 is a block diagram illustrating multiple applications 1020 and1022 that, in one example embodiment, are provided as part of thenetworked system 1002 (see FIG. 1). The applications 1020 may be hostedon dedicated or shared server machines (not shown) that arecommunicatively coupled to enable communications between servermachines. The applications themselves are communicatively coupled (e.g.,via appropriate interfaces) to each other and to various data sources,so as to allow information to be passed between the applications or soas to allow the applications to share and access common data. Theapplications may furthermore access one or more databases 1026 via thedatabase servers 1024.

The networked system 1002 may provide a number of publishing, listingand price-setting mechanisms whereby a seller may list (or publishinformation concerning) goods or services for sale, a buyer can expressinterest in or indicate a desire to purchase such goods or services, anda price can be set for a transaction pertaining to the goods orservices. To this end, the marketplace applications 1020 are shown toinclude at least one publication application 1100 and one or moreauction applications 1102 which support auction-format listing and pricesetting mechanisms (e.g., English, Dutch, Vickrey, Chinese, Double,Reverse auctions etc.). The various auction applications 1102 may alsoprovide a number of features in support of such auction-format listings,such as a reserve price feature whereby a seller may specify a reserveprice in connection with a listing and a proxy-bidding feature whereby abidder may invoke automated proxy bidding.

A number of fixed-price applications 1104 support fixed-price listingformats (e.g., the traditional classified advertisement-type listing ora catalogue listing) and buyout-type listings. Specifically, buyout-typelistings (e.g., including the Buy-It-Now (BIN) technology developed byeBay Inc., of San Jose, Calif.) may be offered in conjunction withauction-format listings, and allow a buyer to purchase goods orservices, which are also being offered for sale via an auction, for afixed-price that is typically higher than the starting price of theauction.

Store applications 1106 allow a seller to group listings within a“virtual” store, which may be branded and otherwise personalized by andfor the seller. Such a virtual store may also offer promotions,incentives and features that are specific and personalized to a relevantseller.

Reputation applications 1108 allow users that transact, utilizing thenetworked system 1002, to establish, build and maintain reputations,which may be made available and published to potential trading partners.Consider that where, for example, the networked system 1002 supportsperson-to-person trading, users may otherwise have no history or otherreference information whereby the trustworthiness and credibility ofpotential trading partners may be assessed. The reputation applications1108 allow a user, for example through feedback provided by othertransaction partners, to establish a reputation within the networkedsystem 1002 over time. Other potential trading partners may thenreference such a reputation for the purposes of assessing credibilityand trustworthiness.

Personalization applications 1110 allow users of the networked system1002 to personalize various aspects of their interactions with thenetworked system 1002. For example a user may, utilizing an appropriatepersonalization application 1110, create a personalized reference pageat which information regarding transactions to which the user is (or hasbeen) a party may be viewed. Further, a personalization application 1110may enable a user to personalize listings and other aspects of theirinteractions with the networked system 1002 and other parties.

The networked system 1002 may support a number of marketplaces that arecustomized, for example, for specific geographic regions. A version ofthe networked system 1002 may be customized for the United Kingdom,whereas another version of the networked system 1002 may be customizedfor the United States. Each of these versions may operate as anindependent marketplace, or may be customized (or internationalizedand/or localized) presentations of a common underlying marketplace. Thenetworked system 1002 may accordingly include a number ofinternationalization applications 1112 that customize information(and/or the presentation of information) by the networked system 1002according to predetermined criteria (e.g., geographic, demographic ormarketplace criteria). For example, the internationalizationapplications 1112 may be used to support the customization ofinformation for a number of regional websites that are operated by thenetworked system 1002 and that are accessible via respective web servers1016.

Navigation of the networked system 1002 may be facilitated by one ormore navigation applications 1114. For example, a search application (asan example of a navigation application) may enable key word searches oflistings published via the networked system 1002. A browse applicationmay allow users to browse various category, catalogue, or systeminventory structures according to which listings may be classifiedwithin the networked system 1002. Various other navigation applicationsmay be provided to supplement the search and browsing applications.

In order to make listings, available via the networked system 1002, asvisually informing and attractive as possible, the marketplaceapplications 1020 may include one or more imaging applications 1116utilizing which users may upload images for inclusion within listings.An imaging application 1116 also operates to incorporate images withinviewed listings. The imaging applications 1116 may also support one ormore promotional features, such as image galleries that are presented topotential buyers. For example, sellers may pay an additional fee to havean image included within a gallery of images for promoted items.

Listing creation applications 1118 allow sellers conveniently to authorlistings pertaining to goods or services that they wish to transact viathe networked system 1002, and listing management applications 1120allow sellers to manage such listings. Specifically, where a particularseller has authored and/or published a large number of listings, themanagement of such listings may present a challenge. The listingmanagement applications 1120 provide a number of features (e.g.,auto-relisting, inventory level monitors, etc.) to assist the seller inmanaging such listings. One or more post-listing management applications1122 also assist sellers with a number of activities that typicallyoccur post-listing. For example, upon completion of an auctionfacilitated by one or more auction applications 1102, a seller may wishto leave feedback regarding a particular buyer. To this end, apost-listing management application 1122 may provide an interface to oneor more reputation applications 1108, so as to allow the sellerconveniently to provide feedback regarding multiple buyers to thereputation applications 1108.

Dispute resolution applications 1124 provide mechanisms whereby disputesarising between transacting parties may be resolved. For example, thedispute resolution applications 1124 may provide guided procedureswhereby the parties are guided through a number of steps in an attemptto settle a dispute. In the event that the dispute cannot be settled viathe guided procedures, the dispute may be escalated to a merchantmediator or arbitrator.

A number of fraud prevention applications 1126 implement fraud detectionand prevention mechanisms to reduce the occurrence of fraud within thenetworked system 1002.

Messaging applications 1128 are responsible for the generation anddelivery of messages to users of the networked system 1002, suchmessages for example advising users regarding the status of listings atthe networked system 1002 (e.g., providing “outbid” notices to biddersduring an auction process or to provide promotional and merchandisinginformation to users). Respective messaging applications 1128 mayutilize any one have a number of message delivery networks and platformsto deliver messages to users. For example, messaging applications 1128may deliver electronic mail (e-mail), instant message (IM), ShortMessage Service (SMS), text, facsimile, or voice (e.g., Voice over IP(VoIP)) messages via the wired (e.g., the Internet), Plain Old TelephoneService (POTS), or wireless (e.g., mobile, cellular, WiFi, WiMAX)networks.

Merchandising applications 1130 support various merchandising functionsthat are made available to sellers to enable sellers to increase salesvia the networked system 1002. The merchandising applications 1130 alsooperate the various merchandising features that may be invoked bysellers, and may monitor and track the success of merchandisingstrategies employed by sellers.

The networked system 1002 itself, or one or more parties that transactvia the networked system 1002, may operate loyalty programs that aresupported by one or more loyalty/promotions applications 1132. Forexample, a buyer may earn loyalty or promotions points for eachtransaction established and/or concluded with a particular seller, andbe offered a reward for which accumulated loyalty points can beredeemed.

The programmable applications 1134 may include the functionality of theprogrammable application 112 (see FIG. 1). For example, the userdesigned applications may enable the client 110 to communicate with oneor more of the applications 1100-1134.

FIG. 12 shows a diagrammatic representation of machine in the exampleform of a computer system 1200 within which a set of instructions may beexecuted causing the machine to perform any one or more of themethodologies discussed herein. In alternative embodiments, the machineoperates as a standalone device or may be connected (e.g., networked) toother machines. In a networked deployment, the machine may operate inthe capacity of a server or a client machine in server-client networkenvironment, or as a peer machine in a peer-to-peer (or distributed)network environment. The machine may be a server computer, a clientcomputer, a personal computer (PC), a tablet PC, a set-top box (STB), aPersonal Digital Assistant (PDA), a cellular telephone, a web appliance,a network router, switch or bridge, or any machine capable of executinga set of instructions (sequential or otherwise) that specify actions tobe taken by that machine. Further, while only a single machine isillustrated, the term “machine” shall also be taken to include anycollection of machines that individually or jointly execute a set (ormultiple sets) of instructions to perform any one or more of themethodologies discussed herein.

The example computer system 1200 includes a processor 1202 (e.g., acentral processing unit (CPU) a graphics processing unit (GPU) or both),a main memory 1204 and a static memory 1206, which communicate with eachother via a bus 1208. The computer system 1200 may further include avideo display unit 1210 (e.g., a liquid crystal display (LCD) or acathode ray tube (CRT)). The computer system 1200 also includes analphanumeric input device 1212 (e.g., a keyboard), a cursor controldevice 1214 (e.g., a mouse), a drive unit 1216, a signal generationdevice 1218 (e.g., a speaker) and a network interface device 1220.

The drive unit 1216 includes a machine-readable medium 1222 on which isstored one or more sets of instructions (e.g., software 1224) embodyingany one or more of the methodologies or functions described herein. Thesoftware 1224 may also reside, completely or at least partially, withinthe main memory 1204 and/or within the processor 1202 during executionthereof by the computer system 1200, the main memory 1204 and theprocessor 1202 also constituting machine-readable media.

The software 1224 may further be transmitted or received over a network1226 via the network interface device 1220.

While the machine-readable medium 1222 is shown in an example embodimentto be a single medium, the term “machine-readable medium” should betaken to include a single medium or multiple media (e.g., a centralizedor distributed database, and/or associated caches and servers) thatstore the one or more sets of instructions. The term “machine-readablemedium” shall also be taken to include any medium that is capable ofstoring, encoding or carrying a set of instructions for execution by themachine and that cause the machine to perform any one or more of themethodologies of the present invention. The term “machine-readablemedium” shall accordingly be taken to include, but not be limited to,solid-state memories, optical and magnetic media, and carrier wavesignals.

Certain systems, apparatus, applications or processes are describedherein as including a number of modules or mechanisms. A module or amechanism may be a unit of distinct functionality that can provideinformation to, and receive information from, other modules.Accordingly, the described modules may be regarded as beingcommunicatively coupled. Modules may also initiate communication withinput or output devices, and can operate on a resource (e.g., acollection of information). The modules be implemented as hardwarecircuitry, optical components, single or multi-processor circuits,memory circuits, software program modules and objects, firmware, andcombinations thereof, as appropriate for particular implementations ofvarious embodiments.

Thus, methods and systems for user-designed application deployment havebeen described. Although the present invention has been described withreference to specific example embodiments, it will be evident thatvarious modifications and changes may be made to these embodimentswithout departing from the broader spirit and scope of the invention.Accordingly, the specification and drawings are to be regarded in anillustrative rather than a restrictive sense.

The Abstract of the Disclosure is provided to comply with 37 C.F.R.§1.72(b), requiring an abstract that will allow the reader to quicklyascertain the nature of the technical disclosure. It is submitted withthe understanding that it will not be used to interpret or limit thescope or meaning of the claims. In addition, in the foregoing DetailedDescription, it can be seen that various features are grouped togetherin a single embodiment for the purpose of streamlining the disclosure.This method of disclosure is not to be interpreted as reflecting anintention that the claimed embodiments require more features than areexpressly recited in each claim. Rather, as the following claimsreflect, inventive subject matter lies in less than all features of asingle disclosed embodiment. Thus the following claims are herebyincorporated into the Detailed Description, with each claim standing onits own as a separate embodiment.

What is claimed is:
 1. A method comprising: deploying a user-designedapplication at a system, the user-designed application causing thesystem to provide a feature that was not provided by the system prior tothe deploying of the user-designed application; receiving a request,from the client device, to access content from the user-designedapplication; and processing the request to determine whether to provideaccess or deny access to the content through the user-designedapplication based on utilization levels of one or more resources of thesystem.
 2. The method of claim 1, wherein processing the request todetermine whether to provide access or deny access to the contentthrough the user-designed application based on the utilization levels ofone or more of the resources of the system further comprising:determining to provide access to the content through the user-designedapplication when utilization of cycles of a central processing unit(CPU) does not exceed a system threshold.
 3. The method of claim 1,wherein processing the request to determine whether to provide access ordeny access to the content through the user-designed application basedon the utilization levels of one or more of the resources of the systemfurther comprising: determining to provide access to the content throughthe user-designed application when utilization of a memory device doesnot exceed a system threshold.
 4. The method of claim 1, whereinprocessing the request to determine whether to provide access or denyaccess to the content through the user-designed application based on theutilization levels of one or more of the resources of the system furthercomprising: determining to provide access to the content through theuser-designed application when utilization of a number of system callsdoes not exceed a system threshold.
 5. The method of claim 1, whereinthe utilization levels includes a system threshold of a resource of thesystem such that access to the content of the user-designed applicationis denied based on utilization of the resource of the system exceeding asystem threshold of the resource of the system.
 6. The method of claim1, further comprising: in response to processing the request anddetermining to provide access to the content through the user-designedapplication, providing access to the content of the user-designedapplication via a plurality of low-level application program interfaces(APIs) embodied as at least one high-level API.
 7. The method of claim1, wherein at least one of the high-level APIs invokes API calls to someof the plurality of low-level APIs simultaneously.
 8. The method ofclaim 1, wherein the feature includes a user-designed interface that isdifferent from a standard interface provided by the system.
 9. Themethod of claim 8, wherein the user-designed interface provides accessto content stored within the system and access to content availableoutside the system via website links or other resources.
 10. The methodof claim 1, further comprising: tracking utilization of one or more ofthe resources of the system.
 11. The method of claim 10, whereintracking the utilization of one or more of the resources of the systemfurther comprising: tracking utilization of one or more of the resourcesof the system associated with the user-designed application.
 12. Themethod of claim 11, further comprising: determining compensationassociated with the user-designed application based on tracking theutilization of one or more of the resources of the system associatedwith the user-designed application.
 13. A system comprising: a memorydevice for storing instructions; a processor, when executing theinstructions, causes the system to perform operations comprising:deploying a user-designed application at a system, the user-designedapplication causing the system to provide a feature that was notprovided by the system prior to the deploying of the user-designedapplication; receiving a request, from a client device, to accesscontent from the user-designed application; and processing the requestto determine whether to provide access or deny access to the contentthrough the user-designed application based on utilization levels of oneor more resources of the system.
 14. The method of claim 13, wherein theutilization levels includes a system threshold of a resource of thesystem such that access to the content of the user-designed applicationis denied based on utilization of the resource of the system exceedingthe system threshold of the resource of the system.
 15. The system ofclaim 13, wherein the processor, when executing the instructions, causesthe system to perform operations further comprising: in response toprocessing the request and determining to provide access to the contentthrough the user-designed application, providing access to the contentof the user-designed application via a plurality of low-level APIsembodied as at least one high-level API.
 16. The system of claim 15,wherein the processor, when executing the instructions, causes thesystem to perform the operation, in response to determining to provideaccess to the content through the user-designed application byprocessing the request, providing access to the content of theuser-designed application via a plurality of low-level APIs embodied asat least one high-level API further comprising: invoking, by at leastone of the high-level APIs, API calls to some of the plurality oflow-level APIs simultaneously.
 17. The system of claim 13, wherein thefeature includes a user-designed interface that is different from astandard interface provided by the system.
 18. The system of claim 13,wherein the processor, when executing the instructions, causes thesystem to perform operations further comprising: tracking utilization ofone or more of the resources of the system associated with theuser-designed application.
 19. The system of claim 13, wherein theprocessor, when executing the instructions, causes the system to performoperations further comprising: determining compensation associated withthe user-designed application based on tracking the utilization of oneor more of the resources of the system associated with the user-designedapplication
 20. A non-transitory machine readable medium storinginstructions that, when executed by a machine, cause the machine toperform operations comprising: deploying a user-designed application ata system, the user-designed application causing the system to provide afeature that was not provided by the system prior to the deploying ofthe user-designed application; receiving a request, from a clientdevice, to access content from the user-designed application; andprocessing the request to determine whether to provide access or denyaccess to the content through the user-designed application based onutilization levels of one or more resources.